IBIS Macromodel Task Group Meeting date: 19 May 2020 Members (asterisk for those attending): Achronix Semiconductor * Hansel Dsilva ANSYS: * Curtis Clark * Wei-hsing Huang Cadence Design Systems: * Ambrish Varma Ken Willis Jared James Intel: * Michael Mirmak Keysight Technologies: Fangyi Rao * Radek Biernacki Ming Yan Todd Bermensolo Stephen Slater Marvell Steve Parker Mentor, A Siemens Business: * Arpad Muranyi Micron Technology: * Randy Wolff * Justin Butterfield SiSoft (Mathworks): * Walter Katz Mike LaBonte Teraspeed Labs: * Bob Ross Zuken USA: * Lance Wang The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - Bob asked that agenda item #8, BIRD181.2_draft2, be assigned to him since Mike LaBonte has been unable to attend ATM meetings. Arpad made the change. ------------- Review of ARs: - Randy to send his BIRD198 draft to the ATM list. - Done. - Hansel to send the Statistical Clocking BIRD draft to Randy for submission to the IBIS Open Forum. - Done, submitted as BIRD205. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the May 12 meeting. Walter moved to approve the minutes. Michael seconded the motion. There were no objections. ------------- New Discussion: BIRD201 - Addressing Radek's comments: Bob noted that he had not yet followed up with editorial changes to Walter's most recent version addressing Radek's comments (bird201.1_draft4). Radek shared a few thoughts on the flow changes. Radek said that step 6 explains what to do when step 5 ends in "Converged". He said we should probably explain what to do if step 5 ends with a BCI_State value of "Error" or "Fail". Walter said he would create a, b, and c, entries for step 6 to explain what do in each case. Radek suggested we might fall back to using the IR from AMI_Init in the "Error" or "Fail" cases. It's as though the training didn't happen in those cases. Walter said he thought all bets are off and the simulation should stop on "Error" or "Fail". Arpad asked what the difference is between "Error" and "Fail". Walter said those were inherited from BIRD147 and asked Ambrish to elaborate. (Note: Ambrish couldn't respond on the call at that time due to audio issues, and we forgot to circle back to the question after he rejoined. We should reintroduce this question at next week's meeting.) Radek noted that some of his suggestions for how to proceed with the editing had mistakenly ended up in the actual text of step 7. Radek suggested that 7a and 7c were identical and could be combined. Walter took and AR to clean up 7. Bob asked about the usage rules for BCI_Training_Mode. He asked if we explicitly stated that the Tx and Rx have to use the same mode. That is, could a tool set "Impulse" if the Tx supported "Impulse" and the Rx supported "Dual"? Walter referred to the first sentence of the Usage Rules section, which states that the tool can only choose a value if it's "available on both the Tx and Rx." Walter said "Dual" means you optimize in statistical mode, and then you pass off to time domain mode and optimize there too. Radek noted that Walter had used "Both" instead of "Dual" in an earlier draft of the BIRD and said he thought "Both" better captured the intended meeting. Walter agreed, and planned to replace "Dual" with "Both". Ambrish asked if Walter could envision a scenario in which the model advertised "Both" but did not support both "Impulse" and "GetWave" as well. Walter said it was allowed. Radek recommended that if "Both" is present then "Impulse" and "GetWave" should also be present. Walter agreed to this change, and the group agreed to the following rules: - Allowable combinations for the model to advertise it supports are: - "Impulse" - "GetWave" - "Impulse" and "GetWave" - "Both", "Impulse", and "GetWave" - If the parameter BCI_Training_Mode is missing, it defaults to "GetWave" - It is illegal to advertise "Both" without both "Impulse" and "GetWave" Bob noted that, for example, if the Tx advertises "GetWave" and the Rx doesn't have BCI_Training_Mode in its .ami file at all, then "GetWave" mode can be used by the tool (Rx defaults to supporting "GetWave"). Walter agreed. Bob suggested the enumerated list of allowable combinations could be added to the Other Notes section. Bob requested that the AMI_Impulse function definition be moved Section 10.2.3 and inserted after the definition of AMI_Init. He said this simplified other changes. For example the definition of AMI_parameters_out for AMI_Impulse could simply state that its definition was identical to that of the same argument to AMI_Init. Ambrish asked why, for example, you can't run one model in "Both" if the other only supports "GetWave"? Radek said the flow wouldn't work in this case because the model running in "Both" mode would expect AMI_Init to be followed by repeated calls to AMI_Impulse, and the model running in "GetWave" mode would expect AMI_Init to be followed by calls to AMI_GetWave. Walter noted that traditionally (BIRD147) we expect the Rx is controlling the training because in many cases the Rx hardware is doing the training. Now we see systems where the Tx is controlling the training. Walter said that the model maker for whichever side is controlling the training is going to choose which mode(s) the model supports. The model maker for the side that is being controlled should probably support all three modes so it can do whatever the controlling side wants. Ambrish asked if Walter could share any results and experiences from his prototyping. Walter said much of his prototyping work had been with the training algorithm in the simulator not the Tx or Rx models. The simulator has access to both the Tx and Rx data and can control both. He said he could demo that flow. He also said he could demonstrate cases with the Rx controlling the training and a proxy Tx model contained inside the Rx, and vice versa. Walter said one can write a proxy Tx and Rx for DDR5 because DDR5 specifies the number of DFE taps, at least for writes. Walter said that for statistical training his prototyping work involves algorithms in the simulator and the use of AMI_Init since he hasn't yet implemented an AMI_Impulse. Walter took an AR to make the technical changes discussed in the meeting to create a draft5 and send it to Bob. Bob took an AR to create a draft6 with his editorial changes. BIRD198.1 editorial discussion: Randy said he had sent his modified version of BIRD198.1, which contains editorial fixes, to the ATM list. He said he had not yet received any feedback. Bob noted one concern about the fact that the example provided for [PDN Domain] includes details about a [PDN Model] before the [PDN Model] keyword is introduced. However, he noted that there is good information within that example. Arpad asked everyone to read the draft and get Randy some feedback. - Curtis: Motion to adjourn. - Radek: Second. - Arpad: Thank you all for joining. AR: Walter to create bird201.1_draft5 with today's changes and email it to ATM. AR: Bob to then add his editorial changes to draft5 to create bird201.1_draft6. ------------- Next meeting: 26 May 2020 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives